graph TD A[Part I] --> B[Digital Engineering] A[Part I] --> C[DEFII] A[Part I] --> D[Digital Thread] B[Digital Engineering] --> E[MBSE] B[Digital Engineering] --> F[Model-Based Engineering] C[DEFII] --> G[Ontology-Aligned Data] C[DEFII] --> H[Automated Reasoning] C[DEFII] --> I[Tool Proxy Interfaces] D[Digital Thread] --> J[Data Flow] D[Digital Thread] --> K[Model Integration] J[Data Flow] --> L[SysML Models] J[Data Flow] --> M[Analysis Tools] K[Model Integration] --> N[IoIF Framework] N[N] --> O[Common Core Ontologies] O[O] --> P[BFO] === == Position in Knowledge Hierarchy *Broader concepts:* - Handbook on Digital Engineering with Ontologies (contains) *Narrower concepts:* - Digital Engineering (is-a) - DEFII (is-a) - Digital Thread (is-a) == Details === Digital Engineering Fundamentals Digital Engineering (DE) represents a paradigm shift from traditional document-based engineering to a model-centric approach where digital models serve as the authoritative source of truth throughout the system lifecycle. As stated in the DoD Digital Engineering Strategy: [QUOTE] "Digital Engineering is the use of digital models to create, test, and validate products and systems throughout their lifecycle, from concept through disposal, to improve performance, reduce cost, and accelerate delivery." [DoD Digital Engineering Strategy, 2018] =--- [NOTE] The Digital Engineering Ecosystem (Figure 65) emphasizes the broader enterprise of modeling and simulation capabilities as well as methodologies (how to), where methodologies embody the process (what) as well as the artifacts (how). === The DEFII Framework The Digital Engineering Framework for Integration and Interoperability (DEFII) provides a structured approach for integrating semantic web technologies into digital engineering contexts. It has three basic layers: [cols="1,2"] |=== |Layer |Description |Ontology-Aligned Data |Foundation of the framework, using ontologies like BFO and CCO as building blocks for interoperable domain ontologies |Automated Reasoning |Enriches data using axioms and rules defined as part of the ontology definitions themselves |Tool Proxy Interfaces |Three categories: Direct Interface, Mapping Interface, and Specified Model Interface |=== [IMPORTANT] DEFII enables "computationally enabled" interoperability by using ontologies as the foundation for data representation and integration, rather than relying on traditional data mapping techniques. === Digital Thread Concept The Digital Thread is the continuous, seamless flow of data across the system lifecycle from concept through disposal. It connects various models and simulations through ontology-aligned data, enabling: * Real-time traceability of requirements * Consistent data across disciplines * Automated impact analysis * Enhanced decision-making capabilities [NOTE] The Digital Thread is not merely a data pipeline but a conceptual framework that enables the integration of mission, system, and analysis models through ontology-aligned data repositories. === Ontologies as the Foundation Why ontologies rather than other information models? Ontologies provide a richer semantic structure than traditional schemas or metamodels: [cols="1,2"] |=== |Information Model Type |Limitations |Ontology Advantages |Schemas |Rigid, limited in expressing logical relations |Express sophisticated logical relations and constraints |Metamodels |Tool-specific, limited to modeling tool capabilities |Tool-agnostic, can express domain knowledge |Ontologies |Requires more initial modeling effort |Enable automated reasoning, cross-domain interoperability |=== [TIP] ==== Use the following process to determine if an ontology is needed: 1. Identify if you need to express complex relationships between domain concepts 2. Determine if you need automated reasoning capabilities 3. Assess if interoperability across multiple domains is required If all three apply, an ontology is likely the right solution. ==== === Ontology Alignment Principles The process of aligning ontologies with digital engineering models follows specific principles: [cols="1,2"] |=== |Principle |Implementation |Use Top-Level Ontologies |BFO (Basic Formal Ontology) provides a stable foundation for domain-specific ontologies |Reuse Existing Ontologies |Leverage mid-level ontologies like CCO (Common Core Ontologies) for common concepts |Clear Naming Conventions |Use descriptive names for classes, properties, and relationships |Consistent Taxonomy |Ensure hierarchical relationships follow established ontological principles |=== [NOTE] "Use clear and descriptive names for your SysML blocks, properties, and OWL classes to ensure readability and maintainability." - From the Catapult exercise == Practical applications and examples === IoIF Workflow Example The Armaments Interoperability and Integration Framework (IoIF) demonstrates how ontologies enable cross-domain model integration. An IoIF workflow for a catapult system example includes: 1. *Model Configuration*: SysML model with Assessment Flow Diagram (AFD) configured to define the analysis workflow 2. *Data Extraction*: Tool proxies pull data from modeling tools (e.g., Creo for geometry) 3. *Ontology Alignment*: Data is mapped to ontology classes using SysML stereotypes 4. *Analysis Execution*: Simulations (e.g., ballistics, aerodynamics) run using data from the ontology-aligned repository 5. *Result Integration*: Analysis results are pushed back to the ontology-aligned repository 6. *Visualization*: Results displayed in Decision and Digital Thread dashboards [mermaid]